<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Cygwin/X X Server
Architecture</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"/><LINK
REL="HOME"
TITLE="Cygwin/X Contributor's Guide"
HREF="cygwin-x-cg.html"/><LINK
REL="UP"
TITLE="Programming"
HREF="programming.html"/><LINK
REL="PREVIOUS"
TITLE="Source Code Tree Layout"
HREF="prog-tree-layout.html"/><LINK
REL="NEXT"
TITLE="Prerequisites for Building the Source Code"
HREF="prog-build-prerequisites.html"/><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html;charset=utf-8"/></HEAD
><BODY
CLASS="sect1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Cygwin/X Contributor's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="prog-tree-layout.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 2. Programming</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="prog-build-prerequisites.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"/></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="prog-server-architecture"
>Cygwin/X X Server
Architecture</A
></H1
><P
>Cygwin/X's X Server architecture was heavily inspired by <A
HREF="biblio.html#porting-layer-definition"
>Angebranndt94</A
>, the Definition of the
Porting Layer for the X v11 Sample Server.</P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="prog-server-architecture-privates"
>Server Privates</A
></H2
><P
>X Servers use various structures to pass information around to
functions.  Some of those structures are colormaps, <A
HREF="glossary.html#gloss-gc"
><I
CLASS="glossterm"
>graphics contexts</I
></A
> (GCs), <A
HREF="glossary.html#gloss-pixmap"
><I
CLASS="glossterm"
>pixmaps</I
></A
>, and <A
HREF="glossary.html#gloss-screen"
><I
CLASS="glossterm"
>screens</I
></A
>.  The X protocol defines
the contents of each of these structures, however, the X Server
implementation and various X Server libraries (<A
HREF="glossary.html#gloss-mi-layer"
><I
CLASS="glossterm"
>MI</I
></A
>, <A
HREF="glossary.html#gloss-fb-layer"
><I
CLASS="glossterm"
>FB</I
></A
>, <A
HREF="glossary.html#gloss-shadow-layer"
><I
CLASS="glossterm"
>Shadow</I
></A
>, etc.)  may require
additional information to be associated with these internal
structures.  For example, the Cygwin/X X Server must associate a
Windows window handle (hwnd) with each X Server screen that is
open.</P
><P
><A
HREF="glossary.html#gloss-privates"
><I
CLASS="glossterm"
>Privates</I
></A
> are the
mechanism provided by the X protocol for associating additional
information with internal X Server structures.  Privates originally
consisted of a single pointer member contained in each structure,
usually named <CODE
CLASS="structfield"
>devPrivate</CODE
> or
<CODE
CLASS="structfield"
>devPriv</CODE
>.  This original specification only
allowed one of the X Server layers (mi, fb, shadow, etc.) to have
privates associated with an internal structure.  Privates have since
been revised.</P
><P
>The current privates implementation requires that each X Server
layer call a function on startup to indicate that that layer will
require privates and to obtain an index into the array of privates
that that layer's privates will be stored at.  Modern privates are
generally stored in an array of type <CODE
CLASS="structname"
>DevUnion</CODE
>
pointed to by a structure member named
<CODE
CLASS="structfield"
>devPrivates</CODE
>;
<CODE
CLASS="structname"
>DevUnion</CODE
> is defined in
<TT
CLASS="filename"
>xserver/include/miscstruct.h</TT
>.  There
are two different memory allocation schemes for
<CODE
CLASS="structfield"
>devPrivates</CODE
>.</P
><P
>Memory for privates structures can either be preallocated or
allocated upon use.  Preallocation, the preferred method for GCs,
pixmaps, and windows, requires that the size of the privates memory
needed be specified during X Server initialization.  Preallocation
allows the <A
HREF="glossary.html#gloss-dix-layer"
><I
CLASS="glossterm"
>DIX</I
></A
> layer
to allocate all memory needed for a given internal structure,
including all privates memory, as a single contiguous block of memory;
this greatly reduces memory fragmentation.  Allocation upon use, used
by screens, requires the <A
HREF="glossary.html#gloss-ddx-layer"
><I
CLASS="glossterm"
>DDX</I
></A
> structure creation function
to allocate memory for the privates;
<CODE
CLASS="function"
>winScreenInit</CODE
> calling
<CODE
CLASS="function"
>winAllocatePrivates</CODE
>, which allocates screen
privates memory directly, is an example of this.  Allocation upon use
can optionally and non-optimally be used by GCs, pixmaps, and
windows.</P
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="prog-server-architecture-privates-macros"
>Macros</A
></H3
><P
>Three macros are provided for each class of privates that make
setting up and using the privates easier.  The macros for screen
privates are examined as an example.</P
><DIV
CLASS="funcsynopsis"
><A
NAME="AEN161"
></A
><P
><CODE
><CODE
CLASS="FUNCDEF"
>winPrivScreenPtr <B
CLASS="FSFUNC"
>winGetScreenPriv</B
></CODE
>(ScreenPtr <VAR
CLASS="PDPARAM"
>pScreen</VAR
>);</CODE
></P
></DIV
><P
><CODE
CLASS="function"
>winGetScreenPriv</CODE
> takes a non-NULL pointer
to a screen, a <SPAN
CLASS="type"
>ScreenPtr</SPAN
>, and returns the pointer stored
in the DDX privates for that screen.  Passing a NULL or invalid
<SPAN
CLASS="type"
>ScreenPtr</SPAN
> to <CODE
CLASS="function"
>winGetScreenPriv</CODE
> will
cause an access violation, crashing the Cygwin/X X Server.</P
><DIV
CLASS="funcsynopsis"
><A
NAME="AEN172"
></A
><P
><CODE
><CODE
CLASS="FUNCDEF"
>void <B
CLASS="FSFUNC"
>winSetScreenPriv</B
></CODE
>(ScreenPtr <VAR
CLASS="PDPARAM"
>pScreen</VAR
>, void * <VAR
CLASS="PDPARAM"
>pvPrivates</VAR
>);</CODE
></P
></DIV
><P
><CODE
CLASS="function"
>winSetScreenPriv</CODE
> takes a non-NULL pointer
to a screen, a <SPAN
CLASS="type"
>ScreenPtr</SPAN
>, and sets the DDX privates
pointer to the value of the <CODE
CLASS="parameter"
>pvPrivates</CODE
>
parameter.  Passing a NULL or invalid <SPAN
CLASS="type"
>ScreenPtr</SPAN
> to
<CODE
CLASS="function"
>winSetScreenPriv</CODE
> will cause an access violation,
crashing the Cygwin/X X Server.</P
><DIV
CLASS="funcsynopsis"
><A
NAME="AEN186"
></A
><P
><CODE
><CODE
CLASS="FUNCDEF"
>void <B
CLASS="FSFUNC"
>winScreenPriv</B
></CODE
>(ScreenPtr <VAR
CLASS="PDPARAM"
>pScreen</VAR
>);</CODE
></P
></DIV
><P
><CODE
CLASS="function"
>winScreenPriv</CODE
> takes a non-NULL pointer to a
screen, a <SPAN
CLASS="type"
>ScreenPtr</SPAN
>, and declares a local variable in the
calling function named <CODE
CLASS="varname"
>pScreenPriv</CODE
>.
<CODE
CLASS="function"
>winScreenPriv</CODE
> may only be called at the top of a
C function within the variable declaration block; calling the function
elsewhere will break the ANSI C rule that all variables must be
declared at the top of a scope block.  Passing a NULL or invalid
<SPAN
CLASS="type"
>ScreenPtr</SPAN
> to <CODE
CLASS="function"
>winScreenPriv</CODE
> will
cause an access violation, crashing the Cygwin/X X Server.</P
></DIV
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="prog-server-architecture-engines"
>Engine System</A
></H2
><P
>The Cygwin/X X Server uses several methods of drawing graphics
on the display device; each of these different drawing methods is
referred to as an engine.  Each of the engines can be classified as
either a Shadow FB engine, a Native GDI engine, or as a Primary FB
engine.  It should be noted that the Primary FB engine is deprecated
and is discussed here only for completeness.  The engines are
discussed in the following sections, in order of importance.</P
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="prog-server-architecture-engines-shadow"
>Shadow FB Engines</A
></H3
><P
>The Shadow FB engines use Keith Packard's <A
HREF="glossary.html#gloss-fb-layer"
><I
CLASS="glossterm"
>FB</I
></A
> drawing procedures wrapped
with his <A
HREF="glossary.html#gloss-shadow-layer"
><I
CLASS="glossterm"
>Shadow</I
></A
>
layer that allows drawing to an <A
HREF="glossary.html#gloss-offscreen-framebuffer"
><I
CLASS="glossterm"
>offscreen
framebuffer</I
></A
> with periodic updates of the <A
HREF="glossary.html#gloss-primary-framebuffer"
><I
CLASS="glossterm"
>primary
framebuffer</I
></A
>.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="prog-server-architecture-engines-native"
>Native GDI
Engine</A
></H3
><P
>The Native GDI engine will eventually translate individual X
graphics calls into their GDI equivalent.  Some X graphics calls do
not translate directly to a GDI call so they may be passed through the
MI layer to change them into a serious of lower level calls that are
supported.  Currently, the Native GDI engine passes all X graphics
calls through the MI layer to convert them into three functions:
<CODE
CLASS="function"
>FillSpans</CODE
>, <CODE
CLASS="function"
>GetSpans</CODE
>, and
<CODE
CLASS="function"
>SetSpans</CODE
>.  The functionality of those three
functions, as of 2001-10-28, is limited to the functionality needed to
draw the familiar X background pattern upon X Server startup.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="prog-server-architecture-engines-primary"
>Primary FB Engine</A
></H3
><P
>The Primary FB engine is deprecated.  Primary FB works in the
same manner that the original Cygwin/X X Server worked, namely, it
uses <CODE
CLASS="function"
>IDirectDrawSurface_Lock</CODE
> to obtain a pointer
to the <A
HREF="glossary.html#gloss-primary-framebuffer"
><I
CLASS="glossterm"
>primary
framebuffer</I
></A
> memory at server startup.  This memory pointer
is held until the X Server shuts down.  This technique does not work
on all versions of Windows.</P
><P
>Locking the primary framebuffer on Windows 95/98/Me causes the
Win16Mutex to be obtained by the program that locks the primary
framebuffer; the Win16Mutex is not released until the primary
framebuffer is unlocked.  The Win16Mutex is a semaphore introduced in
Windows 95 that prevents 16 bit Windows code from being reentered
by different threads or processes.  For compatibility reasons, all GDI
operations in Windows 95/98/Me are written in 16 bit code, thus
requiring that the Win16Mutex be obtained before performing those
operations.  All of this leads to the following situation on Windows
95/98/Me:</P
><OL
TYPE="1"
><LI
><P
>The primary framebuffer is locked, causing the Cygwin/X X
Server to hold the Win16Mutex.</P
></LI
><LI
><P
>Windows switches the Cygwin/X X Server out of the current
process slot; another process is switched in.</P
></LI
><LI
><P
>The newly selected process makes a GDI function call.</P
></LI
><LI
><P
>The GDI function call must wait for the Win16Mutex to be
released, but the Win16Mutex cannot be released until the Cygwin/X X
Server releases the Win16Mutex.  However, the Cygwin/X X Server will
not release the Win16Mutex until it exits.  The end result is that the
Win16Mutex has been deadlocked and the Windows machine is frozen
with no way to recover.</P
></LI
></OL
><P
>Windows NT/2000/XP do not contain any 16 bit code, so the
Win16Mutex is not an issue; thus, the Primary FB engine works fine on
those operating systems.  However, drawing directly to the primary
framebuffer suffers performance problems.  For example, on some
systems writing to the primary framebuffer requires doing memory reads
and writes across the PCI bus which is only 32 bits wide and features
a clock speed of 33 MHz, as opposed to accessing system memory, which
is attached to a 64 bit wide bus that runs at between 100 and 266
(effective) MHz.  Furthermore, accessing the primary framebuffer
memory requires several synchronization steps that take many clock
cycles to complete.  The end result is that the Primary FB engine is
several times slower than the Shadow FB engines.</P
><P
>The Primary FB engine also has several unique issues that are
difficult to program around.  Development of the Primary FB engine has
ceased, due to the difficulty of maintaining it, coupled with the fact
that Primary FB does not run on Windows 95/98/Me and with the poor
performance of Primary FB.  The Primary FB source code has been left
in place so that future programmers can enable it and see the poor
performance of the engine for themselves.</P
></DIV
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="prog-server-architecture-input"
>User Input</A
></H2
><P
>&#13;At the end of <CODE
CLASS="function"
>InitInput</CODE
> in <TT
CLASS="filename"
>hw/xwin/InitInput.c</TT
>
we open <TT
CLASS="filename"
>/dev/windows</TT
>, a special device which becomes ready when there
is anything to read on the windows message queue, and add that to the select mask for
<CODE
CLASS="function"
>WaitForSomething</CODE
> using <CODE
CLASS="function"
>AddEnabledDevice</CODE
>.
</P
><P
>&#13;The X server's main loop calls the <A
HREF="glossary.html#gloss-os-layer"
><I
CLASS="glossterm"
>OS</I
></A
> layer
<TT
CLASS="filename"
>os/WaitFor.c</TT
>'s <CODE
CLASS="function"
>WaitForSomething</CODE
> function, which
waits for something to happen using <CODE
CLASS="function"
>select</CODE
>.
When <CODE
CLASS="function"
>select</CODE
> returns, all the wakeup handlers are run.
Any queued Win32 user input messages (as well as other Win32
messages) are handled when <TT
CLASS="filename"
>hw/xwin/winwakeup.c</TT
>'s
<CODE
CLASS="function"
>winWakeupHandler</CODE
> function is called.
Each Win32 user input message typically queues an input event, or several input
events, using the <A
HREF="glossary.html#gloss-mi-layer"
><I
CLASS="glossterm"
>MI</I
></A
>
layer's <TT
CLASS="filename"
>mi/mieq.c</TT
>'s <CODE
CLASS="function"
>mieqEnqueue</CODE
> function.
</P
><P
>&#13;Enqueued MI input events are processed
when the <A
HREF="glossary.html#gloss-dix-layer"
><I
CLASS="glossterm"
>DIX</I
></A
> layer
<TT
CLASS="filename"
>dix/dispatch.c</TT
>'s <CODE
CLASS="function"
>Dispatch</CODE
>
function calls <TT
CLASS="filename"
>hw/xwin/InitInput.c</TT
>'s
<CODE
CLASS="function"
>ProcessInputEvents</CODE
> function, which calls
<TT
CLASS="filename"
>mi/mieq.c</TT
>'s <CODE
CLASS="function"
>mieqProcessInputEvents</CODE
>.
</P
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="prog-server-architecture-input-keyboard"
>Keyboard</A
></H3
><P
>Win32 keyboard messages are processed in
<TT
CLASS="filename"
>winwndproc.c</TT
>'s
<CODE
CLASS="function"
>winWindowProc</CODE
>.  The messages processed
are:</P
><UL
><LI
><P
>WM_SYSKEYDOWN</P
></LI
><LI
><P
>WM_KEYDOWN</P
></LI
><LI
><P
>WM_SYSKEYUP</P
></LI
><LI
><P
>WM_KEYUP</P
></LI
></UL
><P
>The WM_SYSKEY* messages are generated when the user presses a
key while holding down the <B
CLASS="keycap"
>Alt</B
> key or when the user
presses a key after pressing and releasing the <B
CLASS="keycap"
>F10</B
>
key.  Processing for WM_SYSKEYDOWN and WM_KEYDOWN (and respectively
WM_SYSKEYUP and WM_KEYUP) messages are identical because the X Server
does not distinguish between a normal key press and a key press when
the <B
CLASS="keycap"
>Alt</B
> key is down.</P
><P
>Win32 uses virtual key codes to identify which key is being
pressed or released.  Virtual key codes follow the idea that the same
virtual key code will be sent for keys with the same label printed on
them.  For example, the left and right <B
CLASS="keycap"
>Ctrl</B
> keys both
generate the VK_CONTROL virtual key code.  Virtual key codes are
accompanied by other state information, such as the extended flag,
that distinguishes between the multiple keys with the same label.  For
example, the left <B
CLASS="keycap"
>Ctrl</B
> key does not have the extended
flag asserted, while the right <B
CLASS="keycap"
>Ctrl</B
> key does have the
extended flag asserted.  However, virtual key codes are not the way
that key presses have traditionally been identified on personal
computers and in the X Protocol.</P
><P
>Personal computers and the X Protocol use scan codes to identify
which key is being pressed.  Each key on the keyboard generates a
specified number when that key is pressed or released; this number is
called the scan code.  Scan codes are always distinct for distinct
keys.  For example, the left and right <B
CLASS="keycap"
>Ctrl</B
> keys
generate distinct scan codes, even though their functionality is the
same.  Scan codes do not have additional state information, as the
multiple keys with the same label will each generate a unique scan
code.  There is some debate as to which of virtual key codes or scan
codes is the better system.</P
><P
>The X Protocol expects that keyboard input will be based on a
scan code system.  There are two methods of sending a scan codes from
a virtual key code message.  The first method is to create a static
table that links the normal and extended state of each virtual key
code to a scan code.  This method seems valid, but the method does not
work reliably for users with non-U.S. keyboard layouts.  The second
method simply pulls the scan code out of the
<CODE
CLASS="parameter"
>lParam</CODE
> of the keyboard messages; this method
works reliably for non-U.S. keyboard layouts.  However, there are
further concerns for non-U.S. keyboard layouts.</P
><P
>Non-U.S. keyboard layouts typically use the right
<B
CLASS="keycap"
>Alt</B
> key as an alternate shift key to access an
additional row of symbols from the <B
CLASS="keycap"
>`</B
>,
<B
CLASS="keycap"
>1</B
>, <B
CLASS="keycap"
>2</B
>, ..., <B
CLASS="keycap"
>0</B
> keys,
as well as accented forms of standard alphabetic characters, such as
á, ä, å, ú and additional alphabetic characters, such as ß.
Non-U.S. keyboards typically label the right <B
CLASS="keycap"
>Alt</B
> key
as <B
CLASS="keycap"
>AltGr</B
> or <B
CLASS="keycap"
>AltLang</B
>; the
<ABBR
CLASS="abbrev"
>Gr</ABBR
> is short for <SPAN
CLASS="QUOTE"
>"grave"</SPAN
>, which is the
name of one of the accent symbols.  The X Protocol and Win32 methods
of handling the <B
CLASS="keycap"
>AltGr</B
> key are not directly compatible
with one another.</P
><P
>The X Protocol handles <B
CLASS="keycap"
>AltGr</B
> presses and
releases in much the same way as any other key press and release.
Win32, however, generates a fake <B
CLASS="keycap"
>Ctrl</B
> press and
release for each <B
CLASS="keycap"
>AltGr</B
> press and release.  The X
Protocol does not expect this fake <B
CLASS="keycap"
>Ctrl</B
> press and
release, so care must be taken to discard the fake
<B
CLASS="keycap"
>Ctrl</B
> press and release.  Fake <B
CLASS="keycap"
>Ctrl</B
>
presses and releases are detected and discarded by passing each
keyboard message to <TT
CLASS="filename"
>winkeybd.c</TT
>'s
<CODE
CLASS="function"
>winIsFakeCtrl_L</CODE
> function.
<CODE
CLASS="function"
>winIsFakeCtrl_L</CODE
> detects the fake key presses and
releases by comparing the timestamps of the <B
CLASS="keycap"
>AltGr</B
>
message with the timestamp of any preceding or trailing
<B
CLASS="keycap"
>Ctrl</B
> message.  Two real key events will never have
the same timestamp, but the fake key events have the same timestamp as
the <B
CLASS="keycap"
>AltGr</B
> messages, so the fake messages can be easily
identified.</P
><P
>Special keyboard considerations must be handled when the Cygwin/X X
Server loses or gains the keyboard focus.  For example, the user can
switch out of Cygwin/X, toggle the <B
CLASS="keycap"
>Num Lock</B
> key,
then switch back into Cygwin/X; in this case Cygwin/X would not have
received the <B
CLASS="keycap"
>Num Lock</B
> toggle message, so it will
continue to function as if <B
CLASS="keycap"
>Num Lock</B
> was in its
previous state.  Thus, the state of any mode keys such as <B
CLASS="keycap"
>Num
Lock</B
>, <B
CLASS="keycap"
>Caps Lock</B
>, <B
CLASS="keycap"
>Scroll
Lock</B
>, and <B
CLASS="keycap"
>Kana Lock</B
> must be stored upon loss
of keyboard focus; on regaining focus, the stored state of each mode key must then be
compared to that key's current state, toggling the key if its state
has changed.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="prog-server-architecture-input-mouse"
>Mouse</A
></H3
><P
>Win32 mouse messages are processed in
<TT
CLASS="filename"
>winwndproc.c</TT
>'s
<CODE
CLASS="function"
>winWindowProc</CODE
>.  The messages processed
are:</P
><UL
><LI
><P
>WM_MOUSEMOVE</P
></LI
><LI
><P
>WM_NCMOUSEMOVE</P
></LI
><LI
><P
>WM_LBUTTON*</P
></LI
><LI
><P
>WM_MBUTTON*</P
></LI
><LI
><P
>WM_RBUTTON*</P
></LI
><LI
><P
>WM_MOUSEWHEEL</P
></LI
></UL
><P
>Handling mouse motion is relatively straight forward, with the
special consideration that the Windows mouse cursor must be hidden
when the mouse is moving over the client area of a Cygwin/X window;
the Windows mouse cursor must be redisplayed when the mouse is
moving over the non-client area of a Cygwin/X window.  Win32 sends
the absolute coordinates of the mouse, so we call
<CODE
CLASS="function"
>miPointerAbsoluteCursor</CODE
> to change the position of
the mouse.</P
><P
>Three-button mouse emulation is supported for users that do not
have a three button mouse.  When three-button mouse emulation is
disabled, mouse button presses and releases are handled trivially in
<TT
CLASS="filename"
>winmouse.c</TT
>'s
<CODE
CLASS="function"
>winMouseButtonsHandle</CODE
> by simply passing the event
to <CODE
CLASS="function"
>mieqEnqueue</CODE
>.  Three-button mouse emulation is
quite complicated.</P
><P
>Three-button mouse emulation is handled by starting a timer when
the left or right mouse buttons are pressed; the button event is sent
as a left or right mouse button event if the other button is not
pressed before the timer expires.  The button event is sent as an
emulated middle button event if the other mouse button is pressed
before the timer runs out.</P
><P
>The mouse wheel is handled in <TT
CLASS="filename"
>winmouse.c</TT
>'s
<CODE
CLASS="function"
>winMouseWheel</CODE
> by generating sequences of button 4
and button 5 presses and releases corresponding to how much the mouse
wheel has moved.  Win32 uses variable resolution for the mouse wheel
and passes the mouse wheel motion as a delta from the wheel's previous
position.  The number of button clicks to send is determined by
dividing the wheel delta by the distance that is considered by Win32
to be one unit of motion for the mouse wheel; any remainder of the
wheel delta must be preserved and added to the next mouse wheel
message.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="prog-server-architecture-other-windows-messages"
>Other Windows messages</A
></H3
><P
>&#13;Certain other WM_ messages are also processed. TBD.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"/><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="prog-tree-layout.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="cygwin-x-cg.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="prog-build-prerequisites.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Source Code Tree Layout</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="programming.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Prerequisites for Building the Source Code</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>